1. Avant-propos

Dilbert
Figure 1. Produire des applications

1.1. À qui est destiné ce document?

Les étudiants du DUT informatique, mes collègues enseignants qui cherchent un document de référence accessible, et …​ moi-même (pour organiser mes notes diverses)!

1.2. À qui il n’est pas destiné?

Si vous appartenez à une de ces catégories, ce document n’est pas pour vous :

  • vous cherchez un document de référence

  • vous voulez vous perfectionner

  • vous souhaitez préparer une certification Java ou UML™.

1.3. Historique

Ce document est tout nouveau (date de naissance 05/09/2014!), donc merci de votre indulgence …​

Vous trouverez en référence (cf. Bibiliographie) les ouvrages et autres documents utilisés.

1.4. Sur l’auteur

  • Professeur à l’Université de Toulouse, en poste à l’IUT de Blagnac

  • Co-fondateur de l’association SysML-France

  • Membre du comité éditorial de la revue SoSyM

  • Membre du Steering Committee de la conférence ACM/IEEE MODELS

  • Chef du département informatique de l’IUT de Blagnac 2009 à 2012

  • Responsable de l’ancien module (Analyse et Conception des Systèmes d’Information)

  • Marié à une merveilleuse femme, papa d’une merveilleuse fille

et…​

  • Ancien étudiant du Professeur Benzekri :-)

1.5. Comment lire ce document?

Ce document a été réalisé de manière à être lu de préférence dans sa version électronique (au format HTML ou PDF), ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.

Warning Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, et c’est votre punition pour avoir utilisé du papier au lieu du support électronique!

1.5.1. Conventions typographiques

J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :

  • Les références bibliographiques présentées en fin de document (cf. Bibliographie).

  • Les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons volontairement ces termes (e.g., Package).

Le titre des figures indique (entre parenthèses) un M pour les figures issues de Modelio, un MD pour les figures issues de MagicDraw, un P pour les figures issues de plantUML, un Py pour les figures issues de Papyrus, un R pour les figures issues de Rhapsody, un T pour les figures issues de TOPCASED, un Y pour les figures issues de yuml, et un UK pour les figures en anglais.

Pour les notes, conseils, avertissements, etc. voici la liste des pictogrammes utilisés :

Note

Les notes comme celles-ci sont utilisées pour indiquer des éléments intéressant pour la majorité des lecteurs.
Caution

Ces notes indiquent des points importants qui réclament votre attention.
Tip

Celles-ci concernent en général des points de détail et permettent "d’aller plus loin".
Note
Définition : Exemple (OMG UML v2.4.1, p. 152)

Ces notes concernent des définitions tirées de la spécification UML™ et sont donc précisément référencées.
Note

Modélisation UML incorrecte.
Note

Modélisation UML partiellement correcte ou pouvant prêter à confusion.
Note

Modélisation UML correcte.

1.6. Pourquoi parler de "document"?

Parce que j’ignore la version que vous êtes en train de lire. À partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc :

  • Une version pour le web (Moodle) au format html

  • Une version pour présentation en amphi au format présentation

  • Une version pour impression au format pdf

1.7. Utilisation et autres mentions légales

Les images qui ne sont pas libres de droit contiennent un lien vers les sites où je les ai "empruntées".

N’hésitez pas à m’envoyer vos remarques en tout genre en m’écrivant ici.

1.8. Contenu, objectifs et pré-requis

À faire en dynamique…​

1.9. Supports de cours et matériel

Format des cours

Journées (9h-12h / 14h-17h a priori)

Supports

Pour l’instant : http://jmbruel.heroku.com/teaching/PLM/main.html

Volume

30h (5 jours)

1.10. Outils, exercices et projet

Outils UML™ que nous utiliserons :

  • Editeur Papyrus : l’outil promu par l’aéronautique (Polarsys), Ericsson, etc.

  • plantUML si vous êtes des geek qui aimez les notations textuelles

2. Première partie : modéliser (J1)

2.1. Modéliser c’est quoi ?

2.1.1. Définir un langage de modélisation

idm12
Figure 2. Démarche de définition d’un langage (cf. [IDM'12])

2.1.2. Langages

Pour communiquer il faut un (ou plusieurs) langage(s) :

  • Un modèle (M) n’est pas un langage

    Note Peut être la description d’un langage

  • Un méta-modèle (MM) non plus

2.1.3. Langage, syntaxe, sémantique

Un langage consiste en :

  • une notation syntactique

  • un ensemble d’éléments légaux (combinaison, éventuellement infinie, des termes de base de la notation)

  • une interprétation pour ces termes

    Syntaxe

    ensemble des règles de bon agencement des éléments d’une notation

    Domaine sémantique

    ensemble des interprétations possible pour la notation (« univers du discours »)

    Sémantique

    « mapping » de la syntaxe vers le domaine sémantique

Note

Les 3 éléments de définition d’un langage ont besoin d’être représentés

⇒ 4ème langage parfois!

⇒ différentes couches (e.g., lettres, mots, phrases,…)

2.1.4. Syntaxe

  • Exemples

    • Mots, phrases, déclarations, boîtes, schémas, termes, modules, …

  • Différents types

    • Graphique

    • Textuelle

    • Abstraite

    • Concrète

  • Langage pour la représenter

    • Textuelle ⇒ grammaire

    • Graphique ⇒ graphes

2.1.5. Sémantique

  • Opérationnelle

    • suite d’états et de transitions entre ces états

  • Dénotationnelle

    • fonction mathématique qui fait passer d’un état (entrée de la fonction) à un autre (sortie)

  • Axiomatique

    • propriétés logique sur les états

2.1.6. Modèle

  • Représentation d’un système

    • créé dans un certain objectif

    • utilisé éventuellement pour prédire ou analyser son comportement

  • Description vs. Spécification

    • Description ⇒ système existant

    • Spécification ⇒ système attend

  • Représentation ⇒ relation système/modèle

Objectifs :

  • Appréhender la complexité des systèmes

  • Découpler les considérations

  • Formaliser les éléments intuitifs

  • Dialoguer (interne à l’équipe mais aussi externe)

Différents et nombreux :

  • Instants du cycle de vie

  • Niveau d’abstractions

  • Considérations (vues)

⇒ multiplicité des modèles

Exemple d’UML :

  • Modèles de comportement

  • Modèles des besoins

  • Modèles des données

  • Modèles des communications

  • …​

Notation formelle pour la représentation :

⇒ notion de conformité

⇒ notion de méta-modèle

2.1.7. Méta-modèle et niveaux

M4
Figure 3. Le modèle en 4 couches (source @jeanBezivin)

2.1.8. Importance de la modélisation en informatique

fig placeCentrale
Figure 4. Place centrale

3. Fondements

Pour mener à bien le développement d’un système informatique industriel ou commercial, on ne peut pas improviser. Il s’agit d’un travail impliquant un grand nombre de personnes, des enjeux financiers souvent énormes. Le but de ce cours est de vous faire prendre conscience de cet état de fait autant que de vous donner les différentes techniques liées à cette activité. Au nom de quoi pouvez-vous avoir confiance dans les conseils présentés dans ce cours? Il ne faut pas justement! Il vous faut sans arrêt questionner, remettre en cause les idées reçues.

L’objectif de ce cours est d’aborder la problématique du développement raisonné (de qualité, sûr, rapide, pas cher, etc.) de systèmes. La méthode choisie est celle des études de cas et des applications concrètes.

Les concepts abordés peuvent se classer en différents niveaux [gram86] :

stratégies

règles de comportement général guidant les choix du développeur (par exemple, obtenir le plus rapidement possible un énoncé exécutable relève de la stratégie "prototyper").

tactiques

décrivent des étapes logiques de développement conduisant à un énoncé possédant certaines propriétés (par exemple, passer d’un énoncé imprécis à un énoncé totalement défini relève de la tactique "spécifier").

paradigmes

sont des étapes élémentaires de la construction d’un programme (par exemple, expliciter une entité par un nom et une définition informelle revient à appliquer le paradigme "désigner").

3.1. Stratégies

On vous parlera ici de méthodes, de cycle de vie, de gestion de projet. Mais nous aborderons cela bien plus tard car dans un premier temps cela va être à la fois rébarbatif et très loin de vos préoccupations.

Pour l’instant retenons des principes simples :

  • Comprendre

  • S’organiser

  • Modéliser

  • S’adapter

3.1.1. Comprendre

Théoricien : individu qui n’est pas de votre avis.

— Auguste Detoeuf
découvert dans Le Lexique d'Habrias

Le problème, l’environnement, les outils à maîtriser, la solution attendue, le domaine métier, etc.

3.1.2. S’organiser

Vingt fois sur le métier remettez votre ouvrage : Polissez-le sans cesse et le repolissez ; Ajoutez quelquefois, et souvent effacez.

— N. Boileau

Dans les méthodes agiles on parle de "sprint 0". Il est important de bien s’organiser avant de foncer tête baissée dans le travail à proprement parlé.

Voici quelques éléments importants à aborder :

Démarche globale

Quelle démarche allez-vous mettre en oeuvre (Merise, RUP, Agile, personnelle, …​)?

Rôles

Qui va faire quoi?

Environnement

Quels outils allez-vous utiliser (modélisation, analyse, développement, test, documentation)?

Versionnage

Il est très important, surtout dans un travail collaboratif, de bien utiliser un outil de gestion de version. Que ce soit pour le code (facile), la documentation (moins évident) ou les modèles (très difficile). Pour le code, le nombre de systèmes disponibles vous empêche d’avoir une excuse (Git,Subversion,Mercurial).

3.1.3. Modéliser

Ce que l’on conçoit bien s’énonce clairement. Et les mots pour le dire arrivent aisément.

— N. Boileau

Pour s’abstraire.

3.1.4. S’adapter

Se mettre à jour des techniques. Adapter sa façon de procéder au contexte (au poste que l’on occupe par exemple). Voir Améliorations.

3.2. Tactiques

Liste de tactiques :

  • spécifier

  • décomposition (d’un problème en sous-problème)

  • itération

  • induction (construire un énoncé récursif)

  • approximation (organiser la résolution d’un problème en étudiant d’abord un nouveau problème, considéré comme plus simple)

  • généralisation (formuler et résoudre le problème à un niveau d’abstraction plus général pour permettre ensuite un plus grand nombre d’identifications)

  • réutilisation (exploiter au mieux tout travail déjà fait, cf. aussi [DRY])

3.3. Paradigmes

Liste de paradigmes :

  • désigner

  • typer (décrire les proriétés pertinentes d’une entité)

  • affaiblir (transformer un énoncé pour en réduire la complexité)

  • renforcer (compléter un énoncé par des contraintes supplémentaires)

  • décomposer par cas (lorsqu’on distingue plusieurs traitements suivant les données du problème à un endroit donné)

  • sérialiser (pour définir un résultat, utiliser un résultat intermédiaire x à partir des données, puis exprimer le résultat à partir de x)

  • répartir (définir séparément un certain nombre de sous-résultats, qu’il s’agit ensuite de composer entre eux pour obtenir le résultat attendu)

  • identifier (identifier deux problèmes consiste à reconnaître leur identité au-delà des différences de forme de leurs énoncés)

  • paramétrer (faire abstraction des valeurs particulières de certaines entités, parce qu’elles ne sont pas pertinentes pour l’élaboration de la solution visée)

  • représenter (choisir, pour certaines entités, les types, les relations et le moyen d’expression adéquats)

Les tactiques sont des compositions de paradigmes. Ainsi, la mise en oeuvre de la tactique d’approximation consiste à appliquer le paradigme affaiblir, et le cas échéant le paradigme renforcer pour revenir au problème posé.

3.4. Le Manifeste Agile

Le Manifeste Agile (Agile Manifesto [HighsmithFowler2001]) est un ensemble de principes (voir aussi [1030005] pour une analyse plus récente).

Principe : Satisfaction

Notre plus haute priorité est de satisfaire le client en lui livrant rapidement, et ce, de façon continue un logiciel de qualité.

Principe : Améliorations

À intervalles réguliers, l’équipe réfléchit sur une façon de devenir plus efficace, puis adapte et ajuste son comportement en conséquence.

4. La notation UML

4.1. Méthodologie de développement

Nous allons aborder les points suivants :

  • Pourquoi l’orienté objet ?

  • Pourquoi UML?

  • Processus de développement

  • Conception logicielle

4.1.1. Pourquoi l’orienté objet ?

  • Prendre en compte tout le système

  • Ce que fait le système + comment il est organisé pour le faire

  • Quelques concepts fondamentaux :

    • les objets

    • les messages

    • les classes

    • l’héritage et le polymorphisme

4.1.2. Pourquoi UML?

  • tout le cycle de vie :

    • visualisation

    • spécification

    • construction du système

    • documentation

  • synthèse des meilleurs aspects des méthodes courantes

  • standard mondial

4.1.3. Processus de développement

Activités de bases :

  • Expression des besoins

  • Identification de l’environnement et du contexte

  • Planification

  • Analyse

  • Conception

  • Implémentation

  • Test

  • Révision

Plusieurs approches :

  • Cycle en cascade ("waterfall")

  • En spiral (Boehm)

  • Itératif (RUP, openUP)

    • Inception : évaluation initiale (risques, etc.)

    • Elaboration : architecture, principaux éléments

    • Construction : développement incrémentale

    • Transition : déploiement, formation

  • eXtreme Programming

    • ensembles de "principes"

4.1.4. Conception logicielle

Qu’est-ce qu’une bonne conception?

  • elle est conforme aux besoins fonctionnels / non-fonctionnels

  • elle est modulable et extensible

  • elle est compréhensible et vérifiable

  • elle est aussi simple que possible

Quelques éléments dans ce sens :

  • séparations des responsabilités (e.g., 3-tiers)

  • modularité

  • faible dépendance et forte cohésion

  • utilisation de standards (outils, langages et notations)

Notation pour la conception

  • Cas d’utilisation

  • Diagrammes de classe

  • Diagrammes d’état (statechart)

  • Diagrammes d’interaction (scénarios)

  • Diagrammes de séquence

  • Diagrammes de communication (collaboration)

  • Spécification des opérations et méthodes

  • Diagrammes de flux d’écran

  • Tables de décision

  • CRC

  • …​

4.2. UML en résumé

  • Diagrammes

    • 13 dans la version 2.0

  • Principes généraux

  • Mécanismes

    • paquetages

    • stéréotypes

    • étiquettes

    • notes

    • contraintes

4.3. Enchaînement des modèles

Note Nous utilisons dans ce cours la démarche mise en avant dans [Roques2007a].
pr1
Figure 5. L’objectif de la modélisation : combler le gap entre exigences et code
pr2
Figure 6. Analyse des besoins utilisateurs
pr3
Figure 7. Analyse des besoins utilisateurs
pr4
Figure 8. Analyse des besoins utilisateurs
pr5
Figure 9. Analyse des besoins utilisateurs
pr6
Figure 10. Analyse des besoins utilisateurs
pr7
Figure 11. Analyse des besoins utilisateurs

4.4. Diagramme de classe

Nous souhaitons représenter les données manipulées par le système, ainsi que les relations entre ces données.

plantuml cd
Note

Nous parlons pour l’instant de classe, si vous êtes familié avec le langage C vous pouvez parler de structure. Pour l’instant considérons que les 2 sont équivalents.

4.4.1. Concept de Classe

Une classe est une représentation unique servant à caractériser un ensemble d’objets jouant un rôle identique et décrits par les mêmes attributs.

classe
Warning

Une classe n’est pas un ensemble d’objets!

Afin de faciliter la lisibilité des diagrammes, il est d’usage d’adopter une certaine façon de nommer les différents éléments. Ceci permet d’avoir une homogénéité dans les différents diagrammes.

Note

Exemple de convention d’écriture suivante :

  • 1ère lettre d’une classe toujours en majuscule (la classe Comptes par exemple)

  • mise au singulier des noms
pluriels

4.4.2. Classes et objets

En programmation on parle de type et de variable. Même si c’est un raccourci très rapide nous pouvons pour l’instant faire le parallèle entre les notions de classe et d' objet.

On parlera toutefois d'instance pour désigner un objet issu d’une classe.

object

4.4.3. Attributs

Un attribut est une propriété représentative d’un objet (nom d’une personne, couleur d’une voiture, moyenne d’un étudiant…​).

Pour chaque objet d’une classe, un attribut possède une valeur particulière.

Exemples :

attrib
Note

Nous utiliserons la convention d’écriture suivante pour les attributs :

  • 1ère lettre en minuscule.

  • pour les noms composés, on mettra en majuscule la première lettre de chaque mot, sauf pour le premier.
Tip

Les noms des attributs de type booléen seront précédés du préfixe est (is en anglais).

Exemples :

  • estMajeur vaut VRAI si une personne est majeure et FAUX si elle est mineure

  • estCadre vaut VRAI si une personne est cadre et FAUX sinon

L’intérêt de cette convention permet d’écrire directement des instructions facilement interprétables, comme :

if (estMajeur)
	...

4.4.4. Identifiant

Un identifiant est un attribut particulier d’une classe dont les valeurs représentent sans ambiguïté chaque objet de la classe.

Tip
Choix d’un identifiant

Il faut prendre un attribut non ambigu (le nom d’une personne ne convient pas) et court (le numéro de sécu est trop long).
id
Note

Convention : Les noms des identifiants commenceront par le préfixe id

Vous approfondirez (ou avez déjà abordé) cette notion en Base de donnée.

4.4.5. Association

Une association est un ensemble de liens permanents existant entre les objets de deux ou plusieurs classes. On dira qu’une association lie plusieurs classes ou que les classes participent à l’association.

Note
Exemple

Dans l’exercice sur l’Agence de Voyage, une fiche client est liée à une ou plusieurs commandes en cours.

Dimension d’une association :

Nombre de classes mises en jeu par l’association
(binaire : 2, ternaire : 3, n-aire : n)

Exemple d’association binaire 

Soient les classes Fournisseurs et Produits. On veut indiquer quels sont les produits susceptibles d’être fournis par chaque fournisseur et quels sont les fournisseurs susceptibles de fournir chaque produit.

prod fourn

Nom d’une association :

Afin de clarifier les informations, il est important de nommer les associations.
Il existe trois façons de nommer une association :

  • un verbe à l’infinitif (e.g., Fournir)

  • un verbe conjugué avec un sens de lecture : Fournit > ou < Est fourni par

  • un rôle (placé à une extrémité de l’association)

Note

Un nom d’association commencera par une majuscule comme les noms de classes.

Cardinalité :

Indique à combien d’objets minimum et maximum de la classe d’en face est lié tout objet de la classe de départ. Elle est représentée par un couple (M..N). Elle représente le nombre minimum et maximum d’objets (de la classe de ce côté-ci de l’association) qui peuvent être en association avec un objet donné (de l’autre côté de l’association).

Note

Attention, dans une cardinalité M..N, M doit toujours être inférieur ou égal à N. Exemple : 3..10.

Cardinalités classiques :

  • * : signifie [0..N] avec N indéterminé. Très utilisé pour les associations multiples optionnelles.

  • 1..* : signifie [1..N] avec N indéterminé. Très utilisé pour les associations multiples obligatoires.

  • 1 : signifie [1..1]

4.4.6. Représentation

Représentation des classes

Une classe est représentée par un rectangle divisé en plusieurs compartiments. Le compartiment supérieur contient le nom de la classe et le compartiment inférieur la liste des attributs (l’identifiant est placé en tête de liste).

exp1

Représentation des associations

Une association binaire est représentée par un trait reliant deux classes. Le nom de l’association est placé à proximité du trait et les cardinalités sont placées de part et d’autre.

exp2

4.4.7. Classe association

Certains attributs ne dépendent pas d’une seule classe, mais de plusieurs. Exemple : le prix d’un produit selon le fournisseur qui le propose.

class assoc

Pour les représenter, ils seront placés dans une classe-association reliée au trait de liaison par un trait en pointillés. Le nom de l’association sera alors placé dans la classe-association.

class assoc

4.5. Pour dessiner rapidement de l’UML

Les schémas de cette section sont écrits en utilisant le langage PlantUML.

Par exemple le schéma précédent a été réalisé à partir du code suivant :

@startuml
class Produits {
	idPro
	designation
	poids
}
class Fournisseurs {
	idFour
	raisonSociale
	adresse
}
Produits "0..*" -- "0..*" Fournisseurs : Fournir
@enduml
Note

Vous pouvez tester en ligne : http://www.plantuml.com/plantuml/ ou encore télécharger le [plugin eclipse] (cf. illustration ci-dessous)
plantuml eclipse

4.6. Exercices de révision

  • Réalisez le diagramme de classes suivant :

    1. Les étudiants possèdent un numéro d’étudiant (identifiant), un nom, un prénom, une date de naissance. Ils suivent des cours (titre, code du module).

    2. Les examens concernent un cours donné. Chaque examen a lien à une certaine date et possède un coefficient.

    3. Pour chaque examen un étudiant à une note.

    4. Les cours sont enseignés par un enseignant (nom, prénom)

  • Réalisez le diagramme de classes suivant :

    1. Un portable possède un clavier

    2. Un clavier peut-être de type "azerty" ou "querty"

    3. Un clavier possède des touches

    4. Un portable a un 0 ou 1 propriétaire qui a lui même un nom et un prénom

    5. Un portable a un prix d’achat et une valeur actuelle (souvent différente)

5. Deuxième partie : les incontournables

5.1. Les besoins clients (J2)

Nous aborderons le diagramme des UC et le diagramme de séquence système.

5.2. Le modèle de données (J3)

Il s’agit principalement du diagramme de classe.

5.3. Les diagrammes d’interaction (J4)

Diagramme de séquence et diagramme d’activité

5.4. Documentation, reverse engineering (J5)

5.5. DSL et profils (J5 suite)

6. Diagramme des Cas d’Utilisation

Le Diagramme des Cas d’Utilisation est un modèle UML permettant de représenter :

  • les UC (Use Case ou Cas d’Utilisation)

  • les acteurs (principaux et secondaires)

  • les relations entre acteurs et UC

Note

On notera simplement UC pour signifier "diagramme des UC"

6.1. Définition et concepts

6.1.1. Cas d’Utilisation

Un cas d’utilisation (Use Case ou UC en abrégé) représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.

Exemple d’UC

Retrait par carte bancaire

Scénario principal

L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.

*Scénario alternatif n°1 *

Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.

Exemple de codification de l’UC

UC01 ou RetraitCB (pour Retrait par carte bleue)

Précisions

Un cas d’utilisation peut être précisé par :

  • une description textuelle

  • un ou des diagrammes UML (séquence, activité)

Note

Dans les outils, cette "précision" se manifeste par le fait que l’on "attache" généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un UC → nouveau seq).

6.1.2. Acteur

Un acteur peut être une personne, un ensemble de personnes, un logiciel, un processus qui interagit avec un ou plusieurs UC.

On peut trouver plusieurs types d’acteurs :

  • extérieurs au système (cf. actor Diagramme d’UC ci-après)

    • les acteurs principaux (= acteurs internes du MOT de Merise)

    • les acteurs secondaires (= acteurs externes du MOT de Merise)

    • les administrateurs (ils gèrent le système : données, sécurité, droits d’accès, utilisateurs…​)

  • types d’acteurs prédéfinis dans UML :

    • <<metaclass>>

    • <<utility>>

    • <<process>>

    • <<thread>>

    • <<powertype>>

6.1.3. Relations entre UC

Extension (<<extend>>)

Indique que l’UC source est éventuellement exécutée en complément de l’UC destination (cas particulier, erreur…​)

Inclusion (<<include>>)

Indique qu’un UC est inclus obligatoirement dans un autre UC (notion de sous-programme par exemple)

Généralisation

Relation entre un UC général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute

Notation dans le diagramme d’UC

Diagramme d’UC

Tip

On n’utilise généralement <<include>> que dans le cas où le sous-cas d’utilisation est inclut dans plusieurs UC. Si ce n’est pas le cas, il est généralement englobé dans l’UC.

6.2. Pour construire un UC (de manière générale)

  1. identifier les acteurs

  2. identifier les cas d’utilisation

  3. structurer en packages

  4. ajouter les relations

  5. finaliser les diagrammes de cas d’utilisation

La suite logique est de décrire chaque UC par un diagramme de séquence système (cf. section suivante).

6.3. Exemples complets

6.3.1. Service comptable

Exemple de diagramme d’UC

Exemple de Diagramme d’UC

6.3.2. Gestion des notes

Autre exemple de diagramme d’UC

Exemple de Diagramme d’UC

7. Le Diagramme de Séquence

7.1. Généralités

  • Modélise les interactions entre objets

  • Séquencement dans le temps

  • Échange de messages

  • Spécifie les scénarios des cas d’études

  • Éléments :

    • participants

    • lignes de vie

    • barres d’activation

    • messages

    • blocs (loop,alt,opt,…​)

Diagramme de séquence

Diagramme de séquence Eléments de notation

Warning

Les lignes de vie représentent des objets et non des classes

7.2. Exemple

Exemple de diagramme de séquence

Exemple de diagramme de séquence

7.3. Notions avancées

  • Instructions itératives et conditionnelles

  • Mieux vaut utiliser un diagramme d’activité

  • Cadres d’interaction

    • loop (boucle)

    • alt (alternative)

    • opt (optionel)

    • par (parallèle)

    • region (région critique - un seul thread à la fois)

Exemple algorithme / diagramme

Un algorithme Sa modélisation

7.4. Exemple de conceptions

Conception "centralisée"

Conception 'centralisée'

Conception "objet"

Conception 'objet'

7.5. Diagramme de séquence système

Bien que non présent dans UML, il est courant de trouver un diagramme de séquence particulier, le diagramme de séquence système ou DSS, où on ne représente qu’un seul objet : le système en cours de développement lui-même.

Un exemple de DSS

Exemple de DSS

7.6. Lien entre UC, DSS et DS

La décomposition hiérarchique permet de réaliser une description "TOP-DOWN" du système à réaliser.

On fait un Diagramme de Séquence Système pour chaque UC (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.

Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les objets composants le système (issus du Diagramme de Classes) collaborent pour réaliser le traitement demandé.

Diagramme d’UC

Diagramme d’UC

Le DSS correspondant

Le DSS correspondant

Le DS correspondant

Le DS correspondant

7.7. Le paradigme MVC

Le paradigme Modèle-Vue-Contrôleur, ou MVC (de l’anglais Model-View-Controller) est une architecture logicielle qui divise l’application en trois éléments importants (cf. MVC ci-dessous) :

le modèle

chargé de gérer les élements d’information (comme la base de donnée)

les vues

interfaces entre l’application et l’utilisateur

les contrôleurs

chargés de faire le lien entre vues et modèle.

MVC
Figure 12. Séparation des préoccupations dans le MVC

Bibliographie

  • [gram86] Ana Gram. Raisonner pour programmer. Dunod, 1986.

  • [HighsmithFowler2001] Jim Highsmith and Martin Fowler. The agile manifesto. Software Development Magazine, 9(8) :29–30, 2001.

  • [1030005] Kieran Conboy and Brian Fitzgerald. Toward a conceptual framework of agile methods : a study of agility in different disciplines. In WISER ’04 : Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research, pages 37–44, New York, NY, USA, 2004. ACM.

  • [[IDM'12]] Ingénierie Dirigée par les Modèles : des concepts a la pratique. Jean-Marc Jézéquel, Benoît Combemale, Didier Vojtisek. Ellipses 2012.

  • [Roques2007a] Les Cahiers du Programmeur, UML2, Pascal Roques 3ème Edition, Eyrolles, 2007.

  • [Roques2007b] UML 2 par la pratique, Pascal Roques 6ème Edition, Eyrolles, 2007.

  • [Blanc2006] UML pour les développeurs, Xavier Blanc, Eyrolles, 2006.

  • [Longepe2006] Le projet d’urbanisation du S.I., C. Longépé, 3ème édition, Dunod, 2006.

  • [Gillet2008] Management des SI, M. & P. Gillet, Dunod, 2008.

  • [Muller] Modélisation objet avec UML. {pam} & Nathalie Gaetner, Eyrolles, 2003.

  • [RUP] http://fr.wikipedia.org/wiki/Unified_Process

Glossaire

Note
Ressources

Les définitions ci-dessous sont regroupées à titre indicatif. Les sources utilisées sont :
DRY

Don’t Repeat Yourself :

IHM

Interface Homme-Machine

MCF

Modèle Conceptuel des Flux

MCT

Modèle Conceptuel des Traitements

MOA

Maîtrise d’ouvrage (MOA) Maîtrise d’oeuvre (MOE)

MOF

Modèle Organisationnel des Flux

MOT

Modèle Organisationnel des Traitements

OMG

Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).

PPN

Programme Pédagogique National

SEF

Schéma d'Enchaînement des Fenêtres

SEP

Schéma d'Enchaînement des Pages

SI

Système d'Information

SNI

Schéma de Navigation d'Interfaces

SO

Système Organisationnel

SysML

System Modeling Language ™ : le langage de modélisation de systèmes maintenu par l’OMG™.

TRL

Technology Readiness Level : système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d’évaluer le niveau de maturité d’une technologie (cf. Wikipedia).

URL

Universal Ressource Locator

About…​

Document réalisé par Jean-Michel Bruel via Asciidoctor (version 1.5.3) de 'Dan Allen', lui même basé sur AsciiDoc. Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.